Manufacturing processes and associated industrial process control systems produce a large amount of process information, and software applications are available that provide access in real-time to such information via network connections. Various communication protocols have been used to manage the information flow between networked equipment comprising the process control system. One particular standard is OPC (originally “Object Linking and Embedding for Process Control” and now “Open Platform Communications”), defined and maintained by the OPC Foundation. OPC was originally designed for use by programmers in building programs and systems that allow communication in a Distributed Component Object Model (“DCOM”) system, such as a network of computers, in which component objects can reside on different computers. DCOM is a proprietary Microsoft protocol for communication among software components distributed across networked computers. OPC Unified Architecture (“OPC UA”) is a newer version of the OPC standard which does not rely upon DCOM for communications. OPC provides a distributed client-server architecture for communications within the process control system.
OPC allows automation systems to share information and interoperate with other industrial automation, process control, and other business systems for plants or factories. The OPC standard is a non-proprietary technical specification that is maintained by the OPC Foundation. By providing a framework for a common interface, OPC eliminates the need to write a custom interface (or server/driver) to exchange data with hardware field devices for each product. OPC defines a standard set of interfaces, properties, and methods for use in process control, manufacturing, and automation applications. These applications may include distributed control systems, programmable logic controllers, input/output (IO) systems, smart field devices, and other servers of real-time information. OPC can provide office applications with plant floor data via local area networks (LANs), remote sites, or the Internet.
In many situations, the process control network is located within a secure area, while client applications run on computers coupled to a separate corporate business network that are (or should be) isolated from that secure area. Coupling the separate corporate business network directly to the process control network, without security precautions, can lead to significant security issues, and even a firewall used to couple the two networks can be compromised. OPC does not, however, address how to securely transfer information from a secure process control network to a separate corporate business network.
Alternative network security methods and devices based on unidirectional data transfer have been devised to address the network security concern. For example, U.S. Pat. No. 5,703,562 to Nilsen (“the '562 Patent”), the contents of which are hereby incorporated by reference in its entirety, provides an alternative way to address the network security concern. The '562 Patent discloses a method of transferring data from an unsecured computer to a secured computer over a one-way optical data link comprising an optical transmitter on the sending side and an optical receiver on the receiving side. By providing such an inherently unidirectional data link to a computer/data network to be protected, one can eliminate any possibility of unintended data leakage out of the computer/data network over the same link.
Any data link that strictly enforces the unidirectionality of data flow is called a one-way link or one-way data link. In other words, it is physically impossible to send information or data of any kind through a one-way data link in the reverse direction. A one-way data link may be hardware-based, software-based, or based on some combination of hardware and software.
One-way data transfer systems based on such one-way data links provide network security to data networks by isolating the networks from potential security breaches (i.e., undesired and unauthorized data flow out of the secure network) while still allowing them to import data from the external source in a controlled fashion. FIG. 1 schematically illustrates an example of one such one-way data transfer system 100. In the one-way data transfer system shown in FIG. 1, two computing platforms 101 and 102 (respectively, “the send platform” and “the receive platform”) are connected to the unsecured external network 104 (“the source network”) and the secure network 105 (“the destination network”), respectively. The send platform 101 is connected to the receive platform 102 by a one-way data link 103, which may be an optical link comprising, for example, a high-bandwidth optical fiber. This one-way optical data link 103 may be configured to operate as a unidirectional data gateway from the source network 104 to the secure destination network 105 by having its ends connected to an optical transmitter on the send platform and to an optical receiver on the receive platform.
A configuration such as the one shown in FIG. 1 physically enforces one-way data transfer at both ends of the optical fiber connecting the send platform 101 to the receive platform 102, thereby creating a truly unidirectional data transfer link between the source network 104 and the destination network 105. One-way data transfer systems based on a one-way data link are designed to transfer data or information in only one direction, making it physically impossible to transfer any kind of data, such as handshaking protocols, error messages, or busy signals, in the reverse direction. Such physically imposed unidirectionality in data flow cannot be hacked by a programmer, as is often done with firewalls, where unidirectional rules are software-protected (e.g., password authentication, etc.). Accordingly, the one-way data transfer system based on a one-way data link ensures that data residing on the isolated destination secure computer or network is maximally protected from any undesired and unauthorized disclosure. Alternatively, the source network is isolated from any malware contained in the destination network.
As described in U.S. Pat. No. 8,352,450, issued on Jan. 8, 2013, the contents of which are incorporated herein by reference, files or data packets based on various conventional transport protocols may be transferred across a one-way data link under suitable arrangements. For example, files or data packets may be transferred across a one-way link based on the Transmission Control Protocol (TCP). FIG. 2 is a functional block diagram that schematically illustrates implementation of a TCP-based secure file (or data packet) transfer across a single one-way data link in a one-way data transfer system 200.
Construction of the conventional TCP sockets requires bilateral communications since it requires an acknowledgement channel from the receive node to the send node. Accordingly, the conventional TCP/IP protocol cannot be implemented directly in a one-way data transfer system based on a one-way data link, since no bilateral “hand shaking” is allowed over the one-way link due to physical enforcement of unidirectionality of data flow. Instead, the one-way data transfer system 200 illustrated in FIG. 2 uses a TCP simulation application called TCP proxy, which is preferably a TCP/IP socket-based proxy software, but may also be hardware-based or based on a suitable combination of software and hardware, to simulate the TCP/IP protocol across the one-way data link 207.
In FIG. 2, a TCP server proxy 205 fully implements the TCP/IP protocol in its bilateral communications 203 with the upstream TCP file client 202 residing in a source platform 201. The TCP server proxy 205 may reside within the send node 204 as shown in FIG. 2, or alternatively, may be separate from but coupled to the send node 204. After the TCP server proxy 205 receives files or data packets from the TCP file client 202, the send node 204 sends the files or data packets through its interface 206 to the one-way data link 207. After the receive node 208 receives the files or data packets through its interface 209 from the one-way data link 207, the TCP client proxy 210 communicates under the full implementation of the TCP/IP protocol with a TCP file server 213 residing in a destination platform 212 and forwards the received files or data packets to the TCP file server 213. The TCP client proxy 210 may reside within the receive node 208 as shown in FIG. 2, or alternatively, may be separate from but coupled to the receive node 208.
In certain situations, it would be advantageous to use a one-way data link with an independent link layer protocol for one-way transfer so that non-routable point to point communications with a true IP protocol break can be enforced. With these properties, data packets or files cannot be accidentally routed in the network and other protocols (such as printer protocols, etc.) will not route across the one-way data link. An exemplary configuration enforcing such non-routable point to point communications with a true IP protocol break can be implemented in the one-way file transfer system 200 of FIG. 2. The TCP-based file transfer system 200 may be configured to prohibit transmission of IP information across the one-way data link 207. When the TCP server proxy 205 receives a file from the TCP file client 202, it removes the IP information normally carried in the file data packet headers under the TCP/IP protocol and replaces it with pre-assigned point-to-point channel numbers, so that no IP information is sent across the one-way data link 207. Instead, predetermined IP routes may be defined at the time of the configuration of the system 200 in the form of channel mapping tables residing in the TCP server proxy 205 associated with the send node 204 and the TCP client proxy 210 associated with the receive node 208. The send node 204 then sends the files or data packets with the pre-assigned channel numbers to the receive node 208 through its interface 206 across the one-way data link 207, which are received by the receive node 208 through its interface 209. Upon receipt of the files or data packets, the TCP client proxy 210 then maps the channel numbers from the received files or data packets to the corresponding predetermined IP address of a destination platform 212, to which the files or data packets are forwarded.